Ip handoff process method and system for connection of internet protocols between mobile agents in heterogeneous network

ABSTRACT

An IP handoff process method and Internet service system are provided. In the IP handoff process method, a registration request message for multiple IP handoff is received from a mobile station having a plurality of Internet protocol (IP) addresses through a currently-moving mobile agent of the mobile station. Then, the registration request for multiple IP handoff is processed according to information included in the received registration request message. A reply message thereof is transmitted according to the result of updating the information to the mobile station through the currently-moving mobile agent. Then, the received registration request message is transmitted to a previous mobile agent of the mobile station before moving and a home agent of the mobile station as it is.

TECHNICAL FIELD

The present invention relates to an Internet protocol (IP) handoffprocess method and an Internet service system and, more particularly, toan IP handoff process method and an Internet service system for allowingmultiple IP connections between heterogeneous networks.

BACKGROUND ART

A user terminal using an Internet protocol (IP) may be a mobile nodewith multiple IP addresses such as two wireless broadband (WiBro) ports.Such a mobile node uses the first IP address to transmit and receive IPpacket data and the second IP address as a reserve for themalfunctioning of the first IP address. In this case, the mobile nodemust use multiple IP addresses having an IP address system under thesame medium and the same protocol.

Also, a user terminal may be a mobile node with multiple IP addressessuch as cellular type MIPv6 address 1 and WiBro MIPv6 address 2. Such amobile node uses the first address to transmit and receive IP packetdata and the second address for a streaming service. In this case, themobile node must use multiple IP addresses having the IP address systemof the same protocol although the access medium is different.

As another example, a user terminal may be a mobile node with multipleIP address such as a cellular type MIPv6 address 1 and a sessioninitiation protocol (SIP) type MIPv6 address 2. The mobile node uses twodifferent IP addresses to receive a seamless service when the mobilenode moves from a cellular type MIPv6 supported area to a SIP type MIPv6supported area. In this case, the mobile node must have multiple IPaddresses having an IP address system of different connection media andprotocols.

In trains or airplanes, a mobile network may be provided. Such a mobilenetwork may include various stationary nodes such as a temperaturesensor or a pressure sensor and a portable phone having a wirelesspersonal area network (WPAN). The mobile network can provide services byaccessing the portable phone and the stationary nodes and connecting theportable phone to external networks. In such a case, the mobile networkincludes a mobile router to make a connection to an external network.Such a mobile router functions as a gateway connecting a mobile networkto an external network. A plurality of nodes may exist in the mobilerouter, and have the same or different media and signal protocols forhandoff. Also, the mobile network may include a plurality of mobilerouters to access the external networks, and the mobile routers may usesame or different access mediums and signal protocols for handoff.

A large-sized mobile station such as a passenger ship cruising around along distanced area may include a plurality of mobile networks havingsub networks for each floors of the passenger ship. Each of the mobilenetworks includes multiple mobile routers to make a connection to anexternal network, and the mobile routers may use the same or differentsignal protocols for handoff.

If the mobile nodes (MN) or the mobile routers (MR) are allowed to usemultiple IP addresses or separate subnets as described above, the mobilenodes or mobile routers depend on the policy of a home agent where theMNs and the MRs are belonged to.

As a conventional technology, a mobility management method wasintroduced in U.S. Pat. No. 6,990,339 B2 issued to Turanyi et al. andentitled “Mobility Management for Mobile Hosts”. The introduced mobilitymanagement method can be used for a MIPv4 node and a MIPv6 node. In themobility management method, a network address identifier (NAI) and auser name service (UNS) were introduced. The NAI is placed between ahome agent (HA) and a foreign agent (FA) on a packet path between acorrespondent node (CN) and a mobile node (MN) and prevents packettransmission delay and packet loss which may occur if the HA and the FAintervene whenever packet transmission is delayed or handoff occurs. TheUNS has a function for mapping IP addresses (CoA) of places where a NMvisits. In this method, whenever a MN moves to a FA, the MN transmits anIP address (CoA) obtained from a new FA to a home UNS, and the MN alsotransmits a message to a CN to inform that the MN moves to a new FA sothat the CN obtains the new IP address (CoA) of the MN from the home UNSof the MN to transmit packets. Or, the MN can directly transmit an IPaddress (CoA) obtained from the new FA to the CN after encoding theobtained IP address (CoA). In this case, the CN receives a key value fordecoding the encoded IP address from the home UNS of the MN and obtainsthe IP address of the MN. Then, the CN transmits packets to the obtainedIP address of the MN.

The conventional management method has advantage that a registrationprocedure is not required and the HA or the FA is not included in apacket path. But, the conventional management method requires the CN andthe UNS to have a capability of communicating, and the CN to have thehome UNS of a MN if the CN wants to access the MN before the MN accessesthe CN. That is, backward compatibility problem is arisen. Also, the MNis required to have a function to recognize and transmit relatedmessages to the UNS or the CN. If the home UNS of the MN is located atlong distance, a CN takes long time to obtain an IP address, therebydelaying packet transmission. Therefore, the usability thereof islimited into a mobile node, not into a mobile network.

Another conventional mobility management method was introduced in U.S.Pat. No. 7,065,062 B2 issued at Jun. 20, 2006 and entitled “Mobile Ipmobility management at dormant hand-over in CDMA IP-based cellularpacket-data network”. This mobility management method can be used forMobile IPv4 and Mobile IPv6. This conventional mobility managementmethod is a plan to simplify a complex handoff procedure of a dormantmobile node in a CDMA-2000 mobile phone. It is difficult to perform highspeed handoff required to registration when a mobile node not in adormant state changes a FA, that is, when an active mobile node changesa FA.

Furthermore, a conventional mobility architecture, as another relatedtechnology, was introduced in U.S. Patent Publication No. 2005/0163078A1 published at Jul. 28, 2005, and entitled “Mobility architecture usingpre-authentication, pre-configuration and/or virtual soft-handoff”. Inthe introduced mobility architecture, a pre-authentication for L2 layerof IEEE 802.11 is extended. That is, in order to perform handoff betweenlocal area networks (LAN) having different subnets, a L3 layer ispre-configured and pre-authenticated by sensing a beacon signal of anadjacent access point (AP) is sensed before L2 handoff occurs.Therefore, when an IP handoff occurs according to the movement of amobile node, resources for necessary IP address are previously allocatedin the mobility architecture. The mobile architecture has advantages ofsafe and rapid L3 handoff in networks such as LAN, Home RF, Wi-Fi, CDMA,TDMA, GSM, and CDMA2000. When a mobile node moves and detects a L2 layerbeacon signal of an adjacent area, the mobile node performs thepre-configuration and the pre-authentication of a L3 layer, that is, anIP address before L2 handoff occurs. When the L2 handoff occurs, the MNinstantly changes to the IP address of a current subnet.

The conventional mobility architecture requires a mobile node to have afunction for performing a pre-configuration and a pre-authentication fora L2 handoff before the L2 handoff occurs. Therefore, a terminal used ina typical public mobile communication network cannot be used. Also, a MNis required to determine whether a received beacon signal is a beaconsignal from an AP in a new subnet or not whenever a mobile node receivesbeacon signals from a new AP in the same subnet area. That is, the MN isrequired to process even until the L3 layer to determine whether themobile node moves to different subnets whenever the mobile node receivesa beacon signal of a new AP.

Meanwhile, a handoff process method using a SIP protocol as an IPhandoff method was introduced in rfc2543 of IETF. The handoff processmethod using a SIP protocol is similar to the present invention in aview that a data packet path is separated from a signaling packet path.However, the handoff process method using the SIP protocol requires aSIP redirect server to register whenever IP address changes. Therefore,a handoff time delay becomes lengthened when a mobile node moves faraway from a home network. Also, it is difficult to sustain thecontinuity of TCP session due to the IP address change while a mobilenode is moving. In order to sustain the continuity of TCP session, anInternet technologies supporting universal mobile operation (ITSUMO)project was introduced. That is, when a MN changes an IP address whilesustaining the TCP session, the handoff is processed using informationformed of the original IP address of the MN, the current IP address ofthe MN, the original IP address of a correspondent host using a currentTCP session. However, this method has difficulty to embody a SIPeyeagent in a related correspondent host and all MNs. When a mobile IPv6 isused, a hierarchical MIPv6 registration method was introduced. In thismethod, it requires to be aware of an IP address of an agent of anetwork where a MN visits. That is, the hierarchical MIPv6 registrationmethod also has the regional registration problem.

A high speed handoff method using a satellite was introduced. The highspeed handoff method was developed for voice communication, not for IPpacket. Also, the high speed handoff method has a problem of high costbecause it requires the satellite. In case of using a satellite such asa geostationary satellite, it has a problem of serious time delaybetween a node in an earth and a satellite, and a HOL problem becausepaths for data packet and the handoff signal packet are identical.

In order to overcome problems of conventional handoff technologies, amobile router is required to have a plurality of IP addresses or supportheterogeneous address systems. Also, it requires a method of supportinga mobile network to use a plurality of mobile routers for connectingexternal network.

DISCLOSURE OF INVENTION Technical Problem

An aspect of the present invention is to provide an IP handoffprocessing method and an Internet service system for providing seamlesshandoff although multiple schemes with different IP signal protocols areused in a mobile network having a mobile node using multiple IPaddresses and a plurality of mobile routers.

Another aspect of the present invention is to provide an IP handoffprocess method and an Internet service system for quickly processinghandoff using a typical signal protocol without modifying and forallowing various types of IP handoff signal schemes to be used withoutmodifying the types and contents of signal messages related to handoff.

Technical Solution

According to an aspect of the invention, the invention provides anapparatus including: a method for processing Internet protocol handoffamong a plurality of mobile agents allowing a mobile state having amobile router to use multiple Internet protocols in a mobile agentplatform, the method including: receiving a registration request messagefor multiple IP handoff from a mobile station having a plurality ofInternet protocol (IP) addresses through a currently-moving mobile agentof the mobile station; processing the registration request for multipleIP handoff according to information included in the receivedregistration request message; transmitting a reply message for thereceived registration request message according to the result ofupdating the information to the mobile station through thecurrently-moving mobile agent; and transmitting the receivedregistration request message to a previous mobile agent of the mobilestation before moving and a home agent of the mobile station as it is.

According to another aspect of the invention, the invention provides anInternet protocol handoff processing system for allowing multipleInternet protocols between heterogeneous networks including: a mobilestation having a mobile node and a mobile router; a plurality of mobileagents allowing the mobile station to access multiple IP address at thesame time; and a mobile agent platform (MAP) for receiving a handoffregistration request message for multiple IP access of the mobilestation through a mobile agent where the mobile station visits,instantly transmitting a registration reply message, and transmittingthe received registration request message to a home agent of the mobilestation and a previous agent without modifying the received registrationrequest message.

Advantageous Effects

An IP handoff process method and an Internet service system according tothe certain embodiments of the present invention can provide seamlesshandoff although multiple IP addresses are used or although multipleschemes with different IP signal protocols are used when an IP addresschanges because a mobile node or a mobile network moves to a foreignnetwork. Since the IP handoff processing method and the internet servicesystem according to the present invention allows a conventional signalprotocol to be used without modification, apparatuses using conventionalprotocols can be used without modification and the handoff can bequickly provided.

BRIEF DESCRIPTION OF THE DRAWINGS

The above objects, other features and advantages of the presentinvention will become more apparent by describing the preferredembodiments thereof with reference to the accompanying drawings, inwhich:

FIG. 1 is a diagram illustrating an Internet structure according to anembodiment of the present invention;

FIG. 2 is a diagram illustrating a visitor list table in a mobile agentplatform (MAP) according to an embodiment of the present invention;

FIG. 3 is a diagram illustrating a temp list table in a mobile agentplatform according to an embodiment of the present invention;

FIG. 4 is a diagram illustrating an border list table in a mobile agentplatform according to an embodiment of the present invention;

FIG. 5 and FIG. 6 are diagrams illustrating a capability list table in amobile agent platform according to an embodiment of the presentinvention;

FIG. 7 is a flowchart illustrating a method for processing handoffbetween a mobile agent allowing a plurality of IP accesses and the homeagent of a mobile node according to an embodiment of the presentinvention;

FIG. 8 is a flowchart illustrating a method of processing an IP handoffregistration request in a mobile agent platform (MAP) according to anembodiment of the present invention; and

FIG. 9 is a flowchart illustrating a method of processing an IP handoffregistration response in an MAP according to an embodiment of thepresent invention.

BEST MODE FOR CARRYING OUT THE INVENTION

Hereinafter, preferred embodiments of the present invention will bedescribed in detail with reference to the attached drawings.

Throughout the specification, MNG denotes a mobile node group which is aplurality of nodes for external access, and a MS denotes a mobilestation such as a mobile node and a mobile router included in the MNGfor convenience.

At first, a structure of an Internet network for a plurality of IPhandoff according to an embodiment of the present invention will bedescribed in brief with reference accompanying drawings.

FIG. 1 is a diagram illustrating a structure of an Internet networkaccording to an embodiment of the present invention.

Referring to FIG. 1, the internet service system includes a mobilestation (MS) having a mobile node and a mobile router 101, a pluralityof mobile agents MA1 113, MA2 112, and MA3 111, a mobile agent platform(MAP) for managing the plurality of mobile agents, and a home agent (HA)130.

The MA1 113 denotes an mobile agent where the MS 101 are currentlyvisiting after leaving the area of the MA2 112, and the MA1 113 and theMA3 111 are operated as foreign agents (FA) for the MS 101.

The MA2 112 is a mobile agent that is accessed by the MS 101 before theMS 101 moves to the area of the MA3 111.

If the MS 101 registers to the MA1 113 as a subscriber, the MA1 113becomes the HA of the MS 101.

The HA 130 is a home agent when the MS 101 registers to the other MAlocated at the outside of the MAP 120's area as a subscriber. In FIG. 1,the MAP 120 is shown to be located at the outside of an area 141 forconvenience although a MA in the area 141 of the MAP 120 can become theHA 130.

The IP network 141 becomes an area managed by the MAP 120, and the IPnetwork 142 becomes an area managed by the MAP 121. Although the IPnetworks 141 and 142 are physically adjacent to each others, they can bemutually or directly connected each others. For convenience, the IPnetworks 141 and 142 are shown to pass through a foreign network such asthe Internet in FIG. 1.

MODE FOR THE INVENTION

Hereinafter, a handoff process method for transmitting and receiving ahandoff registration request and a response message thereof between aplurality of mobile agents and a mobile station and between home agentsof the mobile station in an Internet service system will be describedwith reference to accompanying drawings.

In order to process the handoff in the Internet service system describedabove, a mobile agent platform (MAP) includes a visitor list table, atemp list table, a border list table, and a capability list table.Hereinafter, each table will be described in detail with reference toaccompanying drawings.

FIG. 2 is a diagram illustrating a visitor list table in the inside ofthe mobile agent platform according to an exemplary embodiment of thepresent invention.

Referring to FIG. 2, the mobile agent platform includes a plurality ofvisitor list tables classified according to the protocol types. In FIG.2, a protocol type A 301, a protocol type B 302, a protocol type C 303,a protocol type D 304, . . . , and a protocol type n 310 denote tableswhich are visitor lists of mobile stations in an area of MAP, classifiedaccording to protocol types.

For example, the protocol type A 301 may be considered as a visitor listtable following a mobile IPv4 handoff or an IEEE 802.11e handoffprocedure. The protocol type B 302 may be considered as a visitor listtable following a mobile IPv6 handoff procedure. The protocol type C 303may be considered as a visitor list table following a network mobility(NEMO) handoff procedure. The protocol type D 304 may be considered as avisitor list table following a session initiation protocol (SIP)procedure or a procedure for adopting a Binding Unique Identificationnumber (BID), which is under discussion in MONAMI6 Work Group ofInternet Engineering Task Force (IETF). Also, the protocol type n 310may be considered as a visitor list table following an IEEE WorldInteroperability for Microwave Access (WiMAX) procedure.

The protocol type n 310 representatively shows detailed contents of eachof visitor list tables in FIG. 2.

As shown, the each of the visitor list tables includes four columns, afirst column 311, a second column 312, a third column 313, and a fourthcolumn 314. The first column 311 shows visitors within the area of themobile agent platform, i.e., the mobile station. The second column 312shows basic parameters formed of information required for requestingmobile station (MS) registration and allowance thereof. The informationincludes care-of address (CoA), a home agent, a lifetime, and a foreignagent. Therefore, the format of the first and second columns 311 and 312is identical to that of the visitor list table of the conventionalmobile agent platform.

The third column 313 of the visitor list table 310 is set to indicatethat a MS in the first column 311 is one of mobile node groups (MNGs)for determining multiple IP handoff request, or to denote the MS in thefirst column 311 is a node allowed to perform handoff between mobilestations in MNG or protocols. As shown in FIG. 2, the third columns 313for the first and third visitors #1 and #3 are set to ‘o’ whichindicates that the first and third visitors #1 and #3 are one of themobile node groups and are the nodes allowed to perform handoff betweenthe mobile stations or protocols in the mobile node group. The thirdcolumn 313 of the second visitor #2 is set to ‘x’ which indicates thatthe second visitor #2 is not allowed to perform handoff.

The fourth column 314 denotes a location of a capability list if thethird column 313 is set to allow handoff to perform. For example, thefourth column 314 of the visitor #3 and the visitor #4 in the table ofprotocol type n show that the visitor #3 and the visitor #4 are includedin the same group of R2 and it means that two IPs are simultaneouslyused to a mobile terminal or a mobile network using the visitors #3 and#4.

The visitor list tables created by each protocol unit may have the sameformat of the protocol type n table 310.

FIG. 3 is a diagram illustrating a temp list table in a mobile agentplatform according to an exemplary embodiment of the present invention.

Referring to FIG. 3, the MAP includes temp list tables according toprotocol types. In FIG. 3, a protocol type A 401, a protocol type B 402,a protocol type C 403, a protocol type D 404, . . . , and a protocoltype n 410 denote tables which are temp lists of mobile stations in anarea of MAP, classified according to protocol types.

For example, the protocol type A 401 may be considered as a temp listtable following the mobile IPv4 handoff or the IEEE 802.11e handoffprocedure. The protocol type B 402 may be considered as a temp listtable following the mobile IPv6 handoff procedure. The protocol type C403 may be considered as a temp list table following the NEMO handoffprocedure. The protocol type D 404 may be considered as a temp listtable following the SIP procedure or the procedure for adopting the BID,which is under discussion in MONAMI6 Work Group of IETF. Also, theprotocol type n 410 may be considered as a temp list table following theIEEE WiMAX procedure.

The protocol type n 410 representatively shows detailed contents of eachof temp list table in FIG. 3.

As shown, each of the temp list table includes four columns, a firstcolumn 411, a second column 412, a third column 413, and a fourth column414. The first column 411 denotes a visitor, for example, a mobilestation, in an area of the mobile agent platform. The second column 412shows basic parameters formed of information required for registrationrequest and registration allowance of the mobile station. Theinformation may include a care of address (CoA), a home agent, alifetime, and a foreign agent. Therefore, the format of the first andsecond columns 411 and 412 is identical to that in a temp list tableused by a conventional mobile agent platform.

The third column 413 of the temp list table 410 is set to indicate thata MS in the first column 411 is one of mobile node groups (MNGs) fordetermining multiple IP handoff request, or to denote the MS in thefirst column 411 is anode allowed to perform handoff between mobilestations in MNG or protocols. Therefore, the third column 413 for thethird visitor #3 indicates that the third visitor #3 is one of themobile node groups and is the node allowed to perform handoff betweenthe mobile stations in the mobile node group or protocols. The thirdcolumns 413 of the first visitor #1 and the second visitor #2 show thatthe first and second visitors #1 and #2 are not allowed to performhandoff.

The fourth column 414 denotes a location of a capability list if thethird column 413 is set to allow handoff to perform.

Therefore, the temp list tables created according to each protocol ofFIG. 3 have the format identical to that of the protocol type n 410.Excepting the third and fourth columns 413 and 414, the format of thetemp list tables is identical to that of a temp list table used by theconventional mobile agent platform.

FIG. 4 is a diagram illustrating a border list table in a mobile agentplatform according to an exemplary embodiment of the present invention.

Referring to FIG. 4, the mobile agent platform includes a plurality ofborder list tables classified according to used protocol types. In FIG.4, a protocol type A 501, a protocol type B 502, a protocol type C 503,a protocol type D 504, . . . , and a protocol type n 510 denote tableswhich are border lists of mobile stations in an area of MAP, classifiedaccording to protocol types.

For example, the protocol type A 501 may be considered as a border listtable following the mobile IPv4 handoff or the IEEE 802.11e handoffprocedure. The protocol type B 502 may be considered as a border listtable following the mobile IPv6 handoff procedure. The protocol type C503 may be considered as a border list table following the NEMO handoffprocedure.

The protocol type D 504 may be considered as a border list tablefollowing the SIP procedure or the procedure for adopting the BID, whichis under discussion in MONAMI6 Work Group of IETF. Also, the protocoltype n 510 may be considered as a border list table following the IEEEWiMAX procedure.

The protocol type n 510 representatively shows detailed contents of eachof border list table in FIG. 4.

As shown, each of the border list table includes four columns, a firstcolumn 511, a second column 512, a third column 513, and a fourth column514. The first column denotes a visitor, for example, a mobile station,in an area of the mobile agent platform. The second column 512 showsbasic parameters formed of information required for registration requestand registration allowance of the mobile station. The information mayinclude a care of address (CoA), a home agent, a lifetime, and a foreignagent. Therefore, the format of the first and second columns 511 and 512is identical to that in a border list table used by a conventionalmobile agent platform.

The third column 513 is set to indicate that a MS in the first column511 is one of mobile node groups (MNGs) for determining multiple IPhandoff request, or to denote the MS in the first column 511 is anodeallowed to perform handoff between mobile stations in MNG or protocols.Therefore, the third columns 513 for the first and second visitors #1and #2 are one of the mobile node groups and are the node allowed toperform handoff between the mobile stations in the mobile node group orprotocols. The third column 413 of the third visitor #3 show that thethird visitors #3 is not allowed to perform handoff.

The fourth column 514 denotes a location of a capability list if thethird column 513 is set to allow handoff to perform.

Therefore, the border list tables created according to each protocol ofFIG. 4 have the format identical to that of the protocol type n 510.Excepting the third and fourth columns 513 and 514, the format of theborder list tables is identical to that of a border list table used bythe conventional mobile agent platform.

FIGS. 5 and 6 are diagrams illustrating the capability list table in amobile agent platform according to an exemplary embodiment of thepresent invention.

Referring to FIG. 5, the mobile agent platform includes a capabilitylist table 610 denoting whether or not to allow handoff betweendifferent protocols or between mobile stations included in the samemobile node group although the same protocols are used.

The first column in the capability list table 610 is a unique numbercreated by one of mobile stations in a MNG in order to show that the MNGis the same group. For example, the first column is a BID in case ofMONAMI6 WG of IETF. The second column thereof shows the number of theactive mobile stations, which are used within an area of the currentmobile agent platform among the mobile stations included in the mobilenode group. The third column shows that characteristics of the mobilestations included in the mobile node group are stored in a recordformat.

The first row 601 of the capability list table 610 shows mobile stationscorresponding to a group R1. The first row 601 also shows that thenumber of the MSs X1, X2, . . . , X7 in the group R1 is 7 and the numberof currently using mobile stations which are communicating through anagent platform is 2. The second row 602 shows the mobile stationscorresponding to a group R2. The second line 602 shows that the numberof the mobile stations X1, X2, . . . , X6 in the group R2 is 6 and thenumber of currently using mobile stations is 1. Also, the third line 603shows the mobile stations corresponding to a group R3. The third line603 shows that the number of the mobile stations X1, X2, . . . , X6 is 6and the number of currently using mobile stations is 1. Lastly, thefourth line 604 shows the mobile stations corresponding to a group R4.The fourth line 604 shows that the number of mobile stations X1, X2, . .. , X5 in the group R4 is 5 and the number of currently using mobilestations is 3. In FIG. 5, capital letters A,B,C, . . . of X1, . . . ,denote the types of protocols. The capital letters denotes that the IPhandoff is allowed although the protocols are different each others.Small letters denotes that handoff is only allowed between the sameprotocols.

The capability table in FIG. 5 shows that IP handoff is allowed betweennodes X1 and X2 although protocols are different but IP handoff isallowed between node X3 and X4 or between node X3 and X5 only if theyuse the same protocol in case of the group R4 604. Also, the handoff tothe node X1 is not allowed. For example, it is not allowed to convertdata communication by a SIP based mobile phone into data communicationbased on the WiMAX.

FIG. 6 shows a recode denoting characteristics of each MS such as nodesX1, X2, . . . Xn of the capability list 610. A block 611 is a recorddenoting characteristics of a MS X2 of the group R1 601 in FIG. 5. Asshown in the block 611, a protocol used by a MS X2 is a protocol type B,and the MS X2 is in the active state (status: active). The block 611also includes basic parameters required for handoff of the MS X2 such asCoA, Home Address, Lifetime and Home agent. The block 611 includes asupplementary parameter (inter-protocol handoff capability: yes)denoting that IP handoff is allowed between different MSs in the groupR1, and another supplementary parameter (IP handoff capability: yes)denoting that IP handoff is allowed between different MSs using the sameprotocol.

A block 612 is a record denoting characteristics of a MS which is a nodeX4 of the group R4 604 in FIG. 5. As shown in the block 612, a protocolused by a MS X4 is a protocol type d, and the MS X4 is in the not activestate (status: not active). The block 612 also includes basic parametersrequired for handoff of the MS X4 such as CoA, Home Address, Lifetimeand Home agent. As like the block 611, the block 612 also includes asupplementary parameter (inter-protocol handoff capability: no) denotingthat IP handoff is not allowed between different MSs in the group R1,and another supplementary parameter (IP handoff capability: no) denotingthat IP handoff is not allowed between different MSs using the sameprotocol.

Meanwhile, handoff may occur between different protocols with schemedifferently from the configurations shown in the capability list tableof FIG. 5. In this case, an appropriate handoff procedure is performed.For example, handoff from a node X1 to a node X3 in a group R1 may benot directly performed. It is restricted to pass through the node X2 toperform handoff from the node X1 to the node X3. Such a handoff schememay be decided according to the characteristics, functions of each MS,and management policy. Since such a handoff scheme is an applicationlevel matter, it is not discussed in this specification.

Hereinafter, a method of processing multiple IP handoff using not onlythe visitor list, the temp list, and the border list, but also thecapability list that is newly added according to an embodiment of thepresent invent will be described with reference to accompanyingdrawings.

FIG. 7 is a flowchart illustrating a method of processing handoffbetween a mobile agent allowing multiple IP connections and a home agentof a mobile node according to an embodiment of the present invention.

Referring to FIG. 7, at step S201, a MS 101 transmits a handoffregistration request message (Registration Request M_CoA=MA3 IPAddresses) for multiple IP connections to a third mobile agent MA3 111.Herein, the registration request message may be created and transmittedbased on binding unique identification number (BID), which is discussedin MONAMI6 Work Group of IETF (reference:draft-wakikawa-mobileip-multiplecoa-05.txt), or based on a handoffsignal protocol employed between MS and HA of MS.

At step S202, the MA3 111 transfers the received registration requestmessage from the MS 101 to a MAP 120.

If the HA of the MS 101 is located in the area of the MAP 120, the MAP120 instantly transmits a registration response message (Registrationreply) to the MS 101 through the MA3 111 in response to the registrationrequest message for multiple IP connections received from the MAP 120through the MA3 111 at steps S203 and S204.

At step S205, the MAP 120 transfers the registration request messagereceived through the MA3 111 to a MA1 113 that is a HA of the MS 101without modifying the contents thereof, and at step S206, the MAP 120transfers the registration request message to the MA2 112 as it is.

At step S207, the MAP 120 receives the registration replay message fromthe MA1 113, and modifies lifetime information of the MS 101, which isstored in the MAP 120 according to the lifetime stored in the responsemessage. Then, at step S208, the MAP 120 transfers the receivedregistration replay message to the MA2 112 instead of transferring tothe MS 101.

If the home agent of the MS 101 is out of the area of the MAP 120, theMAP 120 transfers the registration request message for multiple IPconnections to the HA 130 of the MS 101 at step S209, and the MAP 120transfers the replay message thereof to the MA3 111 which is a MAvisited by the MS 101 at step S210. In this case, the MA3 111 recognizesthat the registration reply message is transmitted from other MA that isnot MAP 120 and transfers the reply message to the MAP 120 at step S211.

Hereinafter, a procedure of receiving a registration request message forhandoff from a MA in a MAP and processing the received registrationrequest message in a handoff process will be described with reference toaccompanying drawings.

FIG. 8 is a flowchart illustrating a method of processing an IP handoffregistration request in a mobile agent platform (MAP) according to anembodiment of the present invention.

Referring to FIG. 8, at step S701, the MAP 120 receives a registrationrequest message from a mobile agent MA3 111. Herein, since the MAP 120already knew what type of protocol is used in the MA3 111, the MAP 120can receive messages from the MA3 111. Therefore, the MAP 120 searchesor updates a protocol list according to a protocol used by the MA3 111from the visitor list table, the temp list table, and the border listtable as shown in FIG. 2, FIG. 4, FIG. 5, and FIG. 7.

At step S702, the MAP 120 determines whether the received registrationrequest message from the MA is for multiple IP handoff registration ornot. If the received registration request message is not for multiple IPhandoff registration, the MAP 120 performs a conventional registrationrequest processing procedure at step S712. On the contrary, if thereceived registration request message is for multiple IP handoffregistration, the MAP 120 determines whether an entry for acorresponding MS 101 is present in the visitor list table or not at stepS703. If the entry is in the visitor list, the step S707 is performed.If not, the step S704 is performed.

At the step S704, the MAP 120 updates entries of MS in a visitor list bythe received registration request message of MS, and the MAP 120 updatesparameters such as a CoA or whether to use each node or not according toa protocol type and the amount which are requested by a MS based on thecapability list stored therein. The MAP 120 moves the entries of MSincluded in multiple IP handoff registration replay messages requestedby MS from a visitor list to a temp list. Herein, the entries of MS aredeleted from the visitor list.

Afterward, at step S705, the MAP 120 transmits the registration replymessage form the multiple IP handoff registration to the MS 101 througha MA3 111 where the MS 101 belongs instead of the HA 120 of the MS 101.Then, the MAP 120 transmits the received registration request message tothe home agent 130 without modification at step S706.

On the contrary, if the MS 101 is not in the visitor list, the MAP 120determines the MS 101 is in a capability list thereof or not at stepS707. If the MS 101 is in the capability list, step S709 is performed.If not, step S708 is performed.

At step S708, the MAP 120 modifies the entries of MS in the visitor listthereof by the received registration request message of MS, and modifiesparameters such as CoA and whether to use each node or not according toa protocol type and the amount requested by a MS based on the capabilitylist stored therein. Then, the entries of MS included in theregistration request message for multiple IP handoff requested from theMS 101 are added into a temp list, and the step S705 is performed.

On the contrary, if the entry of the MS 101 is not in the capabilitylist thereof, the MAP 120 determines whether the MS 101 is in a borderarea or not at step S709. If the entry of the MS 101 is not in theborder area, the step S705 is performed. If not, it determines whetherthe entry is in a border list or not at step S710. If the entry is notin the border list, the MAP 120 performs the step S705, therebyperforming post processes.

If the entry of the MS 101 is in the border list, the MAP 120 updatesthe entries of MS in the visitor list, and updates the capability liststored in therein. Also, the MAP 120 moves the entries of MSs includedin the registration replay message for multiple IP handoff from theborder list to the temp list. Herein, the entries of MSs are deletedfrom the border list.

Hereinafter, a procedure of receiving a registration reply message forhandoff from a MA and processing the received registration replaymessage at a MAP will be described with reference accompanying drawings.

FIG. 9 is a flowchart illustrating a method of processing an IP handoffregistration response in an MAP according to an embodiment of thepresent invention.

Referring to FIG. 9, at step S801, the MAP 120 receives a registrationreplay message for handoff from a MA1 113 that is a HA of a MS.

At step S802, the MAP 120 determines whether the received message is aresponse for a multiple IP handoff registration request or not.

That is, at step S802, it determines whether a message received from aMA is a registration reply message for multiple IF handoff of a MS ornot. If the received message is not the registration reply message, aconventional registration process procedure is performed at the MAP atstep S815.

On the contrary, if the received message is the registration replymessage, the MAP 120 determines whether or not the registration replymessage includes any one of care of addresses (CoA) that is denied toregister according to an IP handoff registration request. If theregistration relay message does not include such a CoA, a step S806 isperformed. If the registration replay message includes such a CoA, theMAP 120 determines whether the registration denied CoA is in a temp listin a MAP or not. Herein, the registration reply message includes whetherto allow multiple IP addresses of home address and IP handoff or not, aCoA, a lifetime, and a protocol type. After registration, it can bedetermined by the home address at step S804.

If the registration denied CoA is included in the temp list at stepS804, the MAP 120 deletes the entries corresponding to the registrationdenied CoAs in the received registration replay message from the templist of the MAP 120. Then, the MAP 120 modifies the contents of entriescorresponding to CoAs of mobile stations in a capability list of the MAP120, at step S805, and the step S806 is performed. On the contrary ifthe registration denied CoA is not included in the temp list at stepS804, the MAP 120 determines whether entire contents of the receivedregistration response message are registration denial or not at stepS814. If the entire contents are registration denial, the step S812 isperformed. If not, the step S806 is performed, thereby performing postprocesses.

On the contrary, if the registration denied CoA is not in the temp listat step S804, the MAP 120 determines whether de-registered CoAs areincluded in the received registration reply message or not at step S806.If such de-registered CoAs are not included, the step S809 is performed.If such de-registered CoAs are included in the received registrationreply message, the MAP 120 deletes entries corresponding thede-registered CoA from a visitor list and a temp list in the MAP 160 atstep S807. Then, the MAP 120 transfers the registration reply message toa FA having a corresponding CoA and modifies a capability list in theMAP 120 at step S808.

At step S809, the MAP 120 determines whether entries corresponding toremained CoAs in the received registration reply message except theregistration denied CoAs and de-registered CoAs are in a temp list ornot. If such entries in the temp list, the MAP 120 moves the entries ofthe remained CoAs from the temp list to a visitor list according to aprotocol type at step S810, and the MAP 120 deletes the moved entriesfrom the temp list. Herein, the MAP 120 modifies and updates parameterssuch as lifetime according to the contents of registration replymessage, and also modifies a capability list in the MAP 120. Then, thestep S812 is performed.

If the entries corresponding to the remained CoAs are not in the templist at step S809, the MAP 120 creates new entries corresponding toregistration allowance CoAs among entries corresponding to the remainedCoAs, adds the created new entries to a visitor list according to aprotocol type, creates entries corresponding to the registrationresponse message according to the contents of the registration replaymessage, and adds the created entries to the capability list at stepS811.

At step S812, the registration reply message is transferred to theadjacent MAP when the MS 101 is in the border area, and the receivedregistration reply message is transferred to mobile agent where a MScurrently visits as it is at step S813. Then, the described procedure isterminated.

As described above, the handoff process method according to the certainembodiment of the present invention can provide seamless handoffalthough a mobile node or a mobile network uses multiple IP addresses ordifferent schemes with different IP signal protocols when a mobile nodeincluding at least one of external interfaces or a mobile network havingat least one of mobile router changes the IP address thereof by movingto a foreign network. Since the conventional protocol type is usedwithout modification in the certain embodiment of the present invention,devices using the conventional protocol are allowed to be used withoutmodification. Also, it is possible to perform quick handoff.Particularly, various IP handoff signal schemes can be used becausesignal messages related to handoff are not modified in the certainembodiment of the present invention.

Also, the interface of a mobile router MR for accessing a foreignnetwork is not distinguished from an interface of a mobile node in thecertain embodiment of the present invention. In case of a mobile networkhaving a plurality of MRs or a MN having a plurality of interfaces, theyare processed through grouping. Therefore, the mobile network withmultiple MRs or the MN with multiple interfaces can be processedidentically to a mobile terminal with multiple interfaces.

Although the preferred embodiments of the present invention have beendisclosed for illustrative purpose, those skilled in the art willappreciate that various modifications, additions and substitutions canbe made without departing from the scope and spirit of the invention asdefined in the accompanying claims.

INDUSTRIAL APPLICABILITY

An IP handoff process method and an Internet service system for allowingmultiple IP connections between heterogeneous networks are provided. TheIP handoff process method and the Internet service system can provideseamless handoff although a mobile node or a mobile network usesmultiple IP addresses or different schemes with different IP signalprotocols when a mobile node including at least one of externalinterfaces or a mobile network having at least one of mobile routerchanges the IP address thereof by moving to a foreign network. Since theconventional protocol type is used without modification in the certainembodiment of the present invention, devices using the conventionalprotocol are allowed to be used without modification.

1. A method for processing Internet protocol handoff among a pluralityof mobile agents allowing a mobile state having a mobile router to usemultiple Internet protocols in a mobile agent platform, the methodcomprising: receiving a registration request message for multiple IPhandoff from a mobile station having a plurality of Internet protocol(IP) addresses through a currently-moving mobile agent of the mobilestation; processing the registration request for multiple IP handoffaccording to information included in the received registration requestmessage; transmitting a reply message for the received registrationrequest message according to the result of updating the information tothe mobile station through the currently-moving mobile agent; andtransmitting the received registration request message to a previousmobile agent of the mobile station before moving and a home agent of themobile station as it is.
 2. The method according to claim 1, furthercomprising: processing a registration reply for multiple IP handoffaccording to information included in a registration reply message whenthe registration reply message is received from the home agent of themobile station; and transmitting the received replay message to themobile agent according to the registration reply process as it is. 3.The method according to claim 2, further comprising updating lifetimeinformation of the mobile station, which are previously stored accordingto a preset lifetime included in the message through informationincluded in the received reply message.
 4. The method according to claim1, wherein the step of processing the registration request includes:determining whether the mobile station is present in a preset visitorlist or not; and updating entries of the mobile station if the mobilestation is present in the visitor list, moving the updated entries fromthe visitor list to a temp list.
 5. The method according to claim 4,wherein the step of processing the registration request includes:determining whether the mobile station is in a preset capability list ifthe mobile station is not present in the visitor list; moving theentries of the mobile station to from the capability list to the templist if the mobile station is present in the capability list.
 6. Themethod according to claim 5, wherein the step of processing theregistration request includes: determining whether the mobile station ispresent in a preset border list if the mobile station is not present inthe capability list; moving the entries of the mobile station from theborder list to the temp list if the mobile station is present in theborder list.
 7. The method according to claim 3, wherein the step ofprocessing the registration reply includes: determining whether aregistration denied care of address (CoA) is included in CoAs includedin the received registration reply message, which are requested toregister by the mobile station; deleting an entry of the registrationdenied CoA from an internal temp list if the registration denied CoA isin a temp list; and updating an internally preset capability list withthe CoAs requested to register by the mobile station.
 8. The methodaccording to claim 7, wherein the step of processing the registrationreply includes: determining whether de-registered CoA is included in theCoAs requested to register by the mobile station if the register deniedCoA is not included in the CoAs requested to register by the mobilestation; deleting a corresponding entry from an internal preset visitorlist and the temp list if the de-registered CoA is included; andtransferring the registration reply message to a foreign mobile agenthaving the deregistered CoA.
 9. The method according to claim 8, whereinthe step of processing the registration reply includes: determiningwhether entries of remained CoAs requested to register by the mobilestation are present in the temp list or not if the de-registered CoA isnot present; moving entries for the remained CoAs from the temp list tothe visitor list if the entries of the remained CoAs are present in thetemp list; and deleting the entries of the remained CoAs from the templist.
 10. The method according to claim 9, further comprising: creatingnew entries for the remained CoAs if the entries for the remained CoAsare not present in the temp list; adding the created entries to thevisitor list; and creating entries for the registration reply messageand adding the created entries to the capability list.
 11. The methodaccording to claim 6, wherein the capability list denotes whether mobilestations in a mobile node group are allowed to perform handoff betweendifferent protocols or between mobile stations in a same mobile nodegroup although the same protocol is used, and the capability listinclude an unique number denoting the same mobile node group, the numberof mobile stations in an area of a MAP, and characteristics of mobilestations in the same mobile node group in a recode format.
 12. Themethod according to claim 11, wherein the records of the characteristicsof the mobile station included in the capability list include a protocoltype used by a mobile station, information about whether or not tocurrently use, basic parameters for handoff, information about whetheror not to allow handoff between different protocols, and informationabout whether to allow handoff between mobile stations.
 13. The methodaccording to claim 6, wherein the temp list include tables classified bya protocol type used by mobile stations in an area of the MAP.
 14. Themethod according to claim 6, wherein the visitor list includes tablesclassified by a protocol type used by mobile stations in an area of theMAP, and each of the tables includes information about mobile stationsreceiving a service in a related area, basic parameters, informationabout whether or not to request multiple IP handoff, and informationabout a mobile node group location.
 15. The method according to claim 6,wherein the border list includes tables classified by a protocol typeused by mobile stations located at a border area of the MAP, and each ofthe tables includes information about mobile stations receiving aservice, basic parameters, information about whether or not to requestmultiple IP handoff, and mobile node group location information.
 16. AnIP (Internet protocol) handoff processing system for allowing multipleInternet protocols between heterogeneous networks comprising: a mobilestation having a mobile node and a mobile router; a plurality of mobileagents allowing the mobile station to access multiple IP address at thesame time; and a mobile agent platform for receiving a handoffregistration request message for multiple IP access of the mobilestation through a mobile agent where the mobile station visits,instantly transmitting a registration reply message, and transmittingthe received registration request message to a home agent of the mobilestation and a previous agent without modifying the received registrationrequest message.
 17. The IP handoff processing system according to claim16, wherein the mobile agent allows the mobile station to accessmultiple IP at the same time, and the multiple IP is multiple IP in thesame subnet, multiple IP using different subnets, and multiple IP usingdifferent signal protocols.
 18. The IP handoff processing systemaccording to claim 17, wherein the mobile agent platform internallyincludes a visitor list, a temp list, a border list, and a capabilitylist and the mobile agent platform process a registration request and aregistration reply using the lists.
 19. The IP handoff processing systemaccording to claim 18, wherein if the mobile station is present in thevisitor list, the capability list, or the border list based oninformation include in the received registration request message themobile agent platform moves entries of the mobile, the mobile agentplatform moves entries of the mobile station from the corresponding listto a temp list, and transmits the registration reply message.
 20. The IPhandoff processing system according to claim 19, wherein the mobileagent platform searches registration denied care of addresses (CoA) forthe multiple IP handoff registration request from the receivedregistration response message, and deletes entries of the searchedregistration denied CoAs from the temp list, and the mobile agentplatform searches de-registered CoAs if the registration denied CoAs arenot present, and deletes the searched de-registered CoAs from thevisitor list and the temp list.
 21. The IP handoff processing systemaccording to claim 19, wherein if remained CoAs in the receivedregistration reply message except the registration denied CoAs and thede-registered CoAs are present in the temp list, the mobile agentplatform deletes entries of the remained CoAs from the temp list, andmoves the entries to the visitor list.
 22. The IP handoff processingsystem according to claim 21, wherein if remained CoAs in the receivedregistration reply message except the registration denied CoAs and thede-registered CoAs are not present in the temp list, the mobile agentplatform creates new CoAs for the mobile station, adds the created CoAsto the visitor list, creates an entry for the registration replymessage, and adds the created entry to the capability list.
 23. The IPhandoff processing system according to claim 18, wherein the capabilitylist denotes whether mobile stations in a mobile node group are allowedto perform handoff between different protocols or between mobilestations in a same mobile node group although the same protocol is used,and the capability list include an unique number denoting the samemobile node group, the number of mobile stations in an area of a MAP,and characteristics of mobile stations in the same mobile node group ina recode format.
 24. The IP handoff processing system according to claim23, wherein the records for the characteristics of the mobile stationincluded in the capability list include a protocol type used by a mobilestation, information about whether or not to currently use, basicparameters for handoff, information about whether or not to allowhandoff between different protocols, and information about whether toallow handoff between mobile stations.
 25. The method according to claim10, wherein the capability list denotes whether mobile stations in amobile node group are allowed to perform handoff between differentprotocols or between mobile stations in a same mobile node groupalthough the same protocol is used, and the capability list include anunique number denoting the same mobile node group, the number of mobilestations in an area of a MAP, and characteristics of mobile stations inthe same mobile node group in a recode format.
 26. The method accordingto claim 10, wherein the temp list include tables classified by aprotocol type used by mobile stations in an area of the MAP.
 27. Themethod according to claim 10, wherein the visitor list includes tablesclassified by a protocol type used by mobile stations in an area of theMAP, and each of the tables includes information about mobile stationsreceiving a service in a related area, basic parameters, informationabout whether or not to request multiple IP handoff, and informationabout a mobile node group location.